IBIS Macromodel Task Group Meeting date: 02 May 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: * Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: Michael Mirmak * Kinger Cai Chi-te Chen * Liwei Zhao Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Randy: Post draft4 of the IBIS-AMI Ts4file port order BIRD proposal to the Open Forum as an official BIRD. - Done. Randy had sent an email announcing BIRD224. Arpad: Prepare a presentation and statement of the issue for the AMI_GetWave block size with continually adapting models topic. - Not Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 25th meeting. Ambrish moved to approve the minutes. Lance seconded the motion. There were no objections. -------------- New Discussion: How to handle the PSIJ Sensitivity BIRD draft and SPIM (BIRD223): Arpad had added this item to the agenda to facilitate discussion about how to handle these proposals. Should they be part of IBIS, part of a new stand-alone specification, or something else? Walter shared a presentation on where these SPIM and PSIJ models would fit into the overall scheme of IBIS. He started with broad definitions of SI and PI. - Signal Integrity - fundamental question revolves around the shape of the waveform and its transitions and threshold crossings at the latch. - Need to model: - Component internal timing - I/O Buffer Operation - Chip Interconnect - Package Interconnect - Board Interconnect - Connector Interconnect Walter said that given information on the 6 "need to model" items, a simulator can answer the fundamental SI question about the quality of the waveform at the Rx latch. Walter said that IBIS does not address Component Internal Timing. He said it had been discussed in the past, but the situation in the industry is that EDA tools have their own proprietary timing models. There has never been enough desire to come up with a way to standardize it. Sometimes customers may have to put timing data into multiple models/libraries for the various tools, but once that up front step is done things work. Walter also said that IBIS doesn't address board interconnect, though EMD provides similar functionality for modules. He observed that IBIS has a connector interconnect modeling specification, though it was not widely adopted by the industry. Walter said that his organization could have donated their component timing model scheme to IBIS and asked IBIS to "publish" it. If there's interest in that, it could be done in the future. Arpad noted that Walter's list of six items did not include power planes, which could also affect the signal waveform transitions. Walter said his interconnect items included signal and power pins. Arpad said this question would lead into further questions about what is SI versus PI and their convergence. Walter introduced Power Integrity. - Power Integrity - We can solve for the time varying rail voltage waveform. - We can determine the spectral density of that waveform, e.g., the voltage at: - DC - 1kHz - 10kHz - ... - 100GHz - We need to model: Addressed By: - Component load requirements SPIM? - I/O buffer load requirements [Composite Current], SPIM? - VRM (voltage regulator module) - Chip Interconnect IBIS-ISS, SPIM? - Package Interconnect IBIS-ISS, SPIM? - Board Interconnect EMD, EDA vendor? - Connector Interconnect Walter said one question is where SPIM falls in these modeling categories. A second question is whether we should treat SPIM as we have done in the past for component internal timing models. That is, SPIM might be one particular way to do it, but there might be multiple different modeling schemes used to provide component load requirement information, for example. Kinger responded that SPIM's primary focus is on platform PI design. SPIM models the chip and the package, and the model can be given to the platform designer so they can quickly design and verify their platform. Kinger said the goal is to get beyond the existing paradigm of simply specifying a worst case voltage noise amplitude. Kinger said SPIM uses a normalized stimulus, but the stimulus is weighted according to loads on the ports/blocks. This provides scalable load targets. Kinger said that with SPIM you don't have to mix levels (the "need to model" levels). The computer (platform) designer doesn't care about the on-die information. SPIM lets the chip vendor provide a sufficient but minimal amount of information to the platform designer. SPIM, as proposed in BIRD223, provides support for DC and AC analysis and modeling, but it can be extended in the future. Walter said he did not disagree with Kinger. He said Kinger's proposal was valuable, and he thought publishing SPIM 1.0 via IBIS was fine, but it might not be ready to be part of the IBIS specification. He said his concern was that there are lots of models associated with solving SI/PI problems, and IBIS may want to be a host platform for some of the (currently) proprietary models. However, until there's a general desire for SPIM it should be a stand-alone proposal and not necessarily part of the IBIS specification. Kinger said that Intel had been delivering SPIM models to its customers since 2017. He said that since 2015 they had worked with several of the leading EDA companies in this space, together controlling about 90 percent of the market for this platform level PI design software. So, they had a holistic approach with large OEM customers and EDA vendors in favor of this proposal. Kinger said they were offering to open source their SPIM methodology in much the same way they had open sourced their I/O buffer information modeling to create IBIS 30 years ago. Arpad said that IBIS is a modeling language. It allows the model maker to describe buffers, packages, etc. He said SPIM might be filling some gaps in the information IBIS provides. However, his fundamental question was whether SPIM is straying into describing a methodology or simulation flow. He said his opinion was that IBIS should remain a modeling language/specification and not define simulation methodologies and flows. Dian said he thought the question about how to handle SPIM was even more fundamental, should we treat PI modeling as a part of IBIS? Randy and Bob asked whether the tools and users interested in SPIM would care whether SPIM is wrapped inside of IBIS itself? For example, does the IBIS [Component] add something important to SPIM that the tool would use, or could SPIM be a stand-alone specification that refers to IBIS [Component]s. Is the direct linkage to an IBIS file needed for the EDA tools? Kinger and Dian said they thought it would be better to have SPIM in the IBIS specification. It would streamline the syntax and encourage greater adoption of SPIM. Kinger noted that one compromise might be having a dedicated SPIM file and only putting [Device SPIM Group] in the .ibs file. He said that, as is done with [Package Model], we might allow SPIM models directly in the .ibs file or in separate .spim files referred to by .ibs files. Arpad agreed that the current IBIS specification allows us to point to package models in separate files. However, he said we are now discussing whether the specifications (SPIM and IBIS) should be in the same document or separated, versus keeping the models themselves in separate files. - Kinger: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: - None. ------------- Next meeting: 09 May 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives